要了解 OP_SECURETHEBAG（从现在开始，我们将简称为“Secure the Bag”），让我们举一个实际的例子，从基础开始。在这个例子中，12 位客户都要求交易所在费用很高的情况下提款。（实际上，这可能很容易成为 1,200 个客户——但如果有 12 个，这个概念就更容易解释了。）即使没有 Secure the Bag，交易所也是明智的，不会创建 12 次单独的交易来单独支付每个客户。相反，为了节省费用，它创建了一个更紧凑的“批量”交易。交易包括，比如说，三个输入（指“发件人”地址，所有三个都属于交易所）和 12 个输出（包括“收件人”地址，属于不同的客户）。在这个例子中，金额加起来很好，所以没有找零地址。在下图中，交易看起来像右侧的交易 A，而不是左侧显示的 12 个单独的交易。 图片取自 Jeremy Rubin 在 Scaling Bitcoin 2019 上关于 OP_SECURETHEBAG 的演讲因为批量交易包含如此多的输出——每个客户一个——它非常大，数据方面。交易越大，将其包含在区块中的成本就越高。而在高峰时段，交易所要快速确认交易将是相当昂贵的。（不像 12 次单独的交易那样昂贵，但仍然很昂贵。）现在，交易所可以改为包含较低的费用，在这种情况下，交易确认只需要一段时间。但在它确认之前，客户会等待他们的钱，不确定他们是否真的会收到钱：在交易被包含在一个区块中之前，这笔钱可能会被双花。这让客户不满意，交易所也不希望这样。（在某些情况下，甚至可能无法让客户等待：例如，工资单服务可能有合同义务在特定日期确认交易。）这就是 Secure the Bag 的用武之地。Secure the Bag 是一种提议的“操作码”：对比特币编程语言的补充。该操作码本质上会让交易所将其批量交易“拆分”为两个交易：“发送”和“接收”交易。其中第一个——“发送”交易——包括三个原始输入，指的是交易所拥有的地址。但它只包括一个特殊的输出。该输出称为“提交输出”，包含加密哈希：看似随机但相对较短的数字串。这个哈希本质上是一个唯一的序列号，将它链接到两个交易中的另一个：“接收”交易。保护袋子的关键，可以使用提交的输出的唯一方法是通过这个特定的“接收”交易，它通过哈希链接到该交易。（在技术术语中，哈希提交到整个“接收”事务，除了“prevouts”，但这是一个实现细节。）“接收”交易可以被认为是原始交易的后半部分。它只包含一个输入，指的是“发送”交易的提交输出，以及所有 12 个输出。因此，这个带有所有输出的“接收”交易比“发送”交易大得多。在下图中，您可以在左侧看到正常的批量交易，在右侧看到 Secure the Bag 支付的两个独立交易（“发送”和“接收”）。图片取自 Jeremy Rubin 在 Scaling Bitcoin 2019 上关于 OP_SECURETHEBAG 的演讲在向 12 位客户发出提款时，交易所同时广播“发送”和“接收”交易。但是两者之间有一个很大的区别，这就是诀窍的核心。较小的“发送”交易包含相对较大的费用，以确保其快速确认。由于这笔交易很小，从数据上看，即使是相对较大的费用也是可以管理的。 相比之下，较大的“接收”交易包含相对较低的费用，这意味着可能需要一段时间才能确认。但这一次，等待低费用交易确认对客户来说应该不是什么大问题，因为一旦“发送”交易确认，它保证了所有的钱都保证到“接收”交易。这些资金锚定在区块链中，除了给交易所的客户外，别无他处。钱还没有到位……但包已经被固定了。
孩子为父母买单
虽然上面概述的基本示例将确保* 交易所的 12 位客户最终获得资金，但这可能还不能满足所有人的要求。（*如果交易费用从未降到要求的水平，“接收”交易实际上不会自行确认；通过本文其余部分解释的相同技巧解决了这个问题。）例如，12 位顾客之一的 Alice 今天必须向她的房东付款。因此，仅仅知道她最终会从交易所收到钱是不够的——无论她多么确定自己确实会收到钱。她实际上需要能够花费她的产出。 这在技术上是可行的。爱丽丝可以拿走她未确认的输出（12 个中的一个），并立即将其用于新交易。唯一的问题：Alice 的交易只有在“接收”交易也被确认后才会确认。与此同时，她的房东今天要求确认交易。幸运的是，Alice 可以利用一个较旧的比特币技巧来确保“接收”交易和她自己的交易都确认：“孩子为父母付款”（CPFP）。基本上，如果 Alice 在她与房东的交易中包含足够高的费用，矿工将被激励将“接收”交易也包含在一个区块中——即使他们不关心“接收”交易本身的费用. 毕竟，他们只有确认两者才能得到爱丽丝的高额费用。也就是说，补偿大型“接收”交易将非常昂贵。这就是交易所首先使用 Secure the Bag 的原因。现在，Alice 将向所有 12 位客户支付批量交易的费用，而不是交易所。这不会让她成为一个非常满意的顾客。幸运的是，Secure the Bag 提供了更好的解决方案。
树付款
为了解决 Alice 的问题，交易所可以将 Secure the Bag 技巧更进一步。在上面显示的基本示例中，“发送”事务包括一个已提交的输出，而单个“接收”事务包括一个相应的输入和 12 个正常输出。但是可以将这 12 个输出进一步拆分为更多“接收”交易。例如，“发送”交易可以包括两个提交的输出，指的是两个不同的“接收”交易，每个交易都包括六个正常输出。当然，这意味着“发送”交易要快速确认会稍微贵一点，但 Alice 的成本会减半：她现在只需为其他五个客户付款，而不是为 11 个。更好的是，交易所可以在最初的“发送”交易和最终的“接收”交易之间创建“中间”交易！这些“中间”事务都将包括一个输入和一个或多个已提交的输出以及可能的正常输出，从而创建一个树形结构。这样，交易所可以合理地降低CPFP成本，即使对于需要立即花费资金的客户也是如此。匆忙的客户最多需要为与他们相关的中间交易付费，而忽略其余的。如下图所示，交易所可以根据需要创造性地创建这样的树，具体取决于最适合其客户的方式。（更多的中间步骤通常需要在区块链上确认更多的总交易数据——但每个用户的成本更低。“链式”支付类似于树支付，但更依赖于交易的时间顺序。） 图片取自 Jeremy Rubin 在 Scaling Bitcoin 2019 上关于 OP_SECURETHEBAG 的演讲
细节和部署
本文描述了 Secure the Bag 的相当基本的实现。实际上，该提案可以以多种方式实施和利用。例如，Alice 不需要使用 CPFP 来向房东付款，她可以通过闪电通道接收资金并立即通过这些通道向房东付款。还有其他更复杂的解决方案来加速“接收”交易。此外，严格来说，提议的 Secure the Bag OpCode 并不是实现两阶段支付解决方案的唯一方法。即使使用当前的比特币协议，也可以实现类似的效果——但它需要所有接收者协调和合作，这在交易所及其客户的例子中不太可能，而且随着更多用户加入，这种情况会变得更加困难. 其他解决方案（例如契约）将需要比特币协议升级。保护 Bag 也需要通过向后兼容的软分叉来升级协议。Rubin 已经完成了所需的大部分编码工作——尽管代码和想法仍需审查。此外，即使提案通过了所有同行评审，协议升级也可能需要一段时间才能被采用。因此，目前无法估计 Secure the Bag 何时会在比特币上上线——如果有的话。感谢 Jeremy Rubin 提供的信息和反馈。有关 Secure the Bag 的更多信息、模拟数据和各种其他用例，另请参阅相关的比特币改进提案、关于该主题的开发邮件列表讨论（链接：https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08036.html）以及 Rubin 在特拉维夫的 Scaling Bitcoin 2019 上的完整演示。